home *** CD-ROM | disk | FTP | other *** search
/ Compendium Deluxe 1 / LSD Compendium Deluxe 1.iso / a / programming / misc / m2_part1.lha / modula / dice / dice.LHA / doc / dc1.doc < prev    next >
Encoding:
Text File  |  1990-12-13  |  5.9 KB  |  160 lines
  1.  
  2. dc1/dc1                                 dc1/dc1
  3.  
  4.                 DC1.DOC
  5.  
  6.                 MAIN COMPILER PASS
  7.  
  8.     DC1 cppd_src_file [-o outfile] <options>
  9.  
  10.     DC1 is the compiler itself.  As input it requires an already
  11.     preprocessed file and as output it produces assembly.  Many assemblers
  12.     will not be able to assemble the output due to forward referenced REG
  13.     labels and the PROCSTART, PROCEND directives.  The output is normally
  14.     fed to DAS which generates the object file
  15.  
  16.     The compiler generates absolute-data references and absolute code
  17.     references by default.  Do not confuse this with DCC's default, which
  18.     is small-data and small-code.
  19.  
  20.     The compiler will put argument and auto variables into registers
  21.     according to register availability and usage.  It will use A0-A1/D0-D1
  22.     for register variables whenever possible.  Consequently, the most
  23.     heavily used variables will be in registers even for very large
  24.     subroutines.
  25.  
  26.     You should get into the habit of using auto declarations within sub
  27.     blocks rather than declare all your autos at the top of the procedure.
  28.     Apart from making the code more modular, this will enable the compiler
  29.     to make better decisions when allocating register variables.
  30.  
  31.     The output of the compiler generates code of the same order as Aztec or
  32.     Lattice C and, in many cases, makes better choices for register
  33.     variables.    DCC makes much better use of address registers than either
  34.     Aztec or Lattice.  However, it does not do any major contents tracking
  35.     and redundant instructions will be generated.  DAS will handle properly
  36.     optimizing branches and DAS will eventually have a peephole optimizer
  37.     built in it to handle other obvious redundancies.
  38.  
  39.     The compiler does other optimizations itself, such as using bit
  40.     instructions to handle special cases of &, |, and ^, include using
  41.     BTST.
  42.  
  43.                IMPLEMENTATION NOTES
  44.  
  45.     'volatile' forces a data item NOT to be placed in a register.
  46.     'register' is currently ignored.  'const' is ignored by default
  47.     but will force objects into the code section given the -ms or -mS
  48.     options (see below).  Other type and storage qualifiers are described
  49.     in EXTENSIONS.DOC
  50.  
  51.                 OPTIONS
  52.  
  53.     -S or -S0   set alternate section names 'libdata' and 'libbss'
  54.     -Sd <name>  set section name for data sections
  55.     -Sb <name>  set section name for bss sections
  56.     -Sc <name>  set section name for code sections
  57.  
  58.     -SD <name>  set section name for __far data sections
  59.     -SB <name>  set section name for __far bss sections
  60.  
  61.         The -S option allows you to modify the default section naming
  62.         conventions.  DICE uses 'data', 'text', and 'bss' as defaults
  63.         for the data, code, and bss sections.
  64.  
  65.         The DICE c.lib is compiled with -S and the startup code (c.o)
  66.         references these first to force c.lib's data to come before
  67.         program data.  The data ordering is then as follows:
  68.  
  69.         Library Initialized Data
  70.         Program Initialized Data
  71.         Library BSS Space
  72.         Program BSS Space
  73.  
  74.         As long as the program does not declare more than 64KBytes of
  75.         *INITIALIZED* data it can be linked with the small-data model
  76.         c.lib ..  Thus, large-data-model programs that declare more
  77.         than 64KBytes of BSS space will still link with the
  78.         small-data-model c.lib
  79.  
  80.         This may be of no consequence because any __far declared data
  81.         will be placed in a different data segment entirely... simply
  82.         declare your large arrays as __far and the rest may remain
  83.         small-data
  84.  
  85.     -d[#]
  86.  
  87.         Set debug mode.  This isn't pretty
  88.  
  89.     -E file
  90.         specify stderr file, any errors are appended to the file
  91.         instead of to stdout.  Useful for batch compiles
  92.  
  93.  
  94.     -R
  95.  
  96.         Tells the compile to remove (delete) its input file
  97.         specification when it no longer needs it.  The input file
  98.         is usually a temporary preprocessor file and DCC will use
  99.         this option to get DC1 to delete it as soon as possible.
  100.  
  101.     -proto
  102.  
  103.         The main compiler will generate errors for any unprototyped
  104.         function call.
  105.  
  106.     -r
  107.         Resident option.  The main compiler will generate special
  108.         autoinit code to initialize data-data relocations.    This
  109.         simplifies the work DLink and the startup module must do to
  110.         support residentable programs.
  111.  
  112.     -v
  113.  
  114.         Verbose
  115.  
  116.     -o outfile
  117.  
  118.         Specify assembly output file name
  119.  
  120.     -mc        small-code model (DCC default)
  121.     -mC        large-code model (DC1 default)
  122.     -md        small-data model (DCC default)
  123.     -mD        large-data model (DC1 default)
  124.     -mw        absolute-word addressing (overides -md/-mD)
  125.     -ma        absolute addressing (no effect on DC1 operation)
  126.  
  127.         These options specify the memory model.  The small-code model
  128.         uses PC-relative addressing and the small-data model uses
  129.         A4-relative addressing
  130.  
  131.         -mw is used when making ROMable code and specifies that the
  132.         ABSOLUTE WORD addressing mode be used instead of either
  133.         absolute long or A4-relative.   Absolute word addresses are
  134.         resolved at link time.  THIS OPTION SHOULD NOT BE USED WHEN
  135.         GENERATING EXECUTABLES MEANT TO RUN ON THE AMIGA.
  136.  
  137.     -ms0        (default) 'const' is ignored
  138.     -ms        string constants and 'const' objs placed in code section
  139.     -mS        string constants and 'const' objs placed in code section
  140.  
  141.         These options control how CONST data items are handled, including
  142.         string constants such as char *ptr = "abcd";  The default is to
  143.         ignore the const type qualifier.
  144.  
  145.         If -ms is specified string constants and CONST data items are
  146.         placed in the code section.  Local references to CONST data
  147.         items use PC-RELATIVE addressing.  Remote references (from other
  148.         modules) to CONST data items use ABSOLUTE LONG addressing.
  149.  
  150.         -mS works the same as -ms but remote references are forced to
  151.         use PC-RELATIVE addressing.  This can be dangerous and the
  152.         final CODE size MUST BE LESS THAN 32KBYTES!!!!
  153.  
  154.         Usually it is safe to use -ms and, in fact, can save a lot of
  155.         memory when combined with -r residentable programs because the
  156.         string constants will not be duplicated for each running
  157.         instance of the program.
  158.  
  159.  
  160.